Back-of-the-Envelope Cheatsheet
Napkin math for system design. Use powers of 1000, never apologize for rounding.
1. The core trick: multiply, then count zeros
bytes/item × items = total. Work in powers of 10. Every ×1000 moves you up one unit:
B → KB → MB → GB → TB → PB. So 3 zeros per step.
| Unit | Bytes (approx) | Zeros |
|---|
| 1 KB | 103 = 1,000 | 3 |
| 1 MB | 106 = 1,000,000 | 6 |
| 1 GB | 109 | 9 |
| 1 TB | 1012 | 12 |
| 1 PB | 1015 | 15 |
Memorize these anchor products
| Per item | × 1 thousand | × 1 million | × 1 billion |
|---|
| 1 byte | 1 KB | 1 MB | 1 GB |
| 100 bytes | 100 KB | 100 MB | 100 GB |
| 1 KB | 1 MB | 1 GB | 1 TB |
| 1 MB | 1 GB | 1 TB | 1 PB |
Sanity check from the interview: 100 bytes × 1M users = 100 MB. (Not 100 GB — that would be 100 bytes × 1B, or 100 KB × 1M.)
2. QPS / throughput conversions
1 day ≈ 100,000 seconds (actually 86,400, round to 105). So
per-day ÷ 100,000 = per-second.
| Volume | ≈ QPS | How |
|---|
| 1 million / day | ~12 /s | 106 / 105 |
| 10 million / day | ~120 /s | bump one zero |
| 100 million / day | ~1,200 /s | |
| 1 billion / day | ~12,000 /s | 109 / 105 |
| 1 billion / month | ~400 /s | ÷ 30 days more |
Peak factor: multiply average QPS by ~2–3× for peak, and provision for peak.
3. Common datastore sizes (single node, rules of thumb)
Redis (in-memory)
| Throughput | ~100K ops/s |
| Latency | <1 ms |
| Practical RAM/node | 25–100 GB |
| Hard ceiling | RAM-bound |
It's a cache. If your dataset > RAM you shard, full stop.
Postgres (disk)
| Writes/node | ~5K–10K/s |
| Reads (w/ replicas) | 10s of K/s |
| Comfortable size | up to a few TB |
| Row (rough) | ~1 KB |
Vertical scale + read replicas first. Shard only when writes or size force it.
| Store | Use for | Ballpark cap / node |
|---|
| Redis / Memcached | cache, counters, sessions | ~100 GB, 100K ops/s |
| Postgres / MySQL | transactions, relational | ~few TB, ~10K w/s |
| Cassandra / Dynamo | high write, wide scale | scales horizontally by design |
| Kafka | event stream / log | ~1M+ msg/s (cluster) |
| S3 / object store | blobs, backups | effectively unbounded |
4. When to scale horizontally / shard
Shard when a single node hits any one ceiling: RAM, disk, or throughput. Reach for the cheaper levers first.
- Vertical first. Bigger box. Cheap, no code change, buys you a lot.
- Read replicas. When reads >> writes and you're read-bound.
- Cache layer. Before sharding the DB, put Redis in front.
- Shard (partition) when:
- Redis dataset > ~50–100 GB, or ops > ~100K/s
- Postgres write throughput > single-node limit (~10K/s)
- Dataset > a few TB, or working set no longer fits RAM
- How to shard: consistent hashing (minimal key movement when adding nodes). Watch for hot keys / uneven partitions.
5. Latency numbers (order of magnitude)
| Operation | Time | Mental anchor |
|---|
| L1 cache reference | ~1 ns | free |
| Main memory (RAM) reference | ~100 ns | 100× L1 |
| Read 1 MB sequentially from RAM | ~0.25 ms | |
| SSD random read (4 KB) | ~150 µs | ~1000× RAM |
| Read 1 MB from SSD | ~1 ms | |
| Round trip, same datacenter | ~0.5 ms | the Redis hop |
| Disk seek (spinning) | ~10 ms | avoid |
| Read 1 MB from spinning disk | ~20 ms | |
| Round trip, cross-region (CA↔EU) | ~100–150 ms | the expensive one |
Rough ladder: RAM 100 ns → SSD 100 µs → same-DC network 0.5 ms → disk seek 10 ms → cross-region 100 ms.
Each rung is roughly 100–1000× the last. Memory is ~1M× faster than a cross-region hop.
6. Fast facts to keep handy
Time
- 1 day ≈ 86,400 s ≈ 105 s
- 1 month ≈ 2.6M s ≈ 2.5×106
- 1 year ≈ 31.5M s ≈ 3×107
Sizes of common things
- char/int: 1–8 bytes · UUID: 16 B · timestamp: 8 B
- Short text row: ~100 B–1 KB
- Web page / small image: ~100 KB–1 MB
- 1 min 1080p video: ~50 MB
7. Worked example (the pattern to repeat)
Q: 500M daily active users, each posts 2 tweets/day, 300 bytes each. Storage per year?
- Writes/day = 500M × 2 = 109 → QPS = 109 / 105 = ~12K writes/s (peak ~25K)
- Bytes/day = 109 × 300 = 3×1011 = 300 GB/day
- Per year = 300 GB × 365 ≈ ~110 TB/year (before replication/index)
- ×3 replication → ~330 TB → clearly needs sharding + object storage for media